Most software applications include a graphical user interface (hereinafter “GUI”). A GUI is a visual environment that contains movable and re-sizeable windows, drop-down menus, graphics, buttons, slide bars and other items that can be manipulated by using a pointing device (e.g., mouse, track ball, tablet or stylus). One way in which GUIs are used is configuration settings for software applications. Many software applications and development tools offer configuration menus in which a user may view configuration settings as well as make changes. In such an environment, radio boxes and/or check boxes are often used to display and change settings. Such settings are often represented as a boolean value (e.g., a setting is either “on” (TRUE) or “off” (FALSE)). Typically a check box will contain a check mark if the configuration item being represented is “on”. If a checkbox does not contain a check mark, the configuration item being represented is “off”. FIG. 1 illustrates a GUI-based configuration menu containing check boxes and radio buttons.
GUI-based environments differ from a character-based (hereinafter “CB”) environment or console. First, CB environments do not contain non character drawn graphics.
That is, CB environments are usually comprised of textual characters (e.g., ASCII characters) only. There are no check boxes and radio buttons that can be manipulated to change settings. It is common for the number “1” to represent “yes” and the number “2” to represent “no”. For example, a user may be presented with an option to enable “automatic disk de-fragmentation”. A CB menu may state that typing “1” and the ENTER key means “yes” or typing “2” and the ENTER key means “no”.
FIG. 2 illustrates a CB configuration menu. In FIG. 2, horizontal characters “-” are used to create separators between menu items. In this example, a separator exists between menu items 1 and 6, 9 and 11, 15 and 16, etc. It is also possible to indent certain menu items to depict a hierarchical structure amongst menu items. FIG. 2 displays such a hierarchy to show that sub-menu items may exist under a root menu item. For example, menu item 9 appears to be indented in order to show that it is a sub-menu item of item 8. Further, sub-menu items 19-24 are also indented to show that these items may only apply to menu item 18.
Existing CB environments (e.g., the prior art) only offer static or scripted menus. A complex array of character-based menus is hard-coded into the software of the application it represents. If changes to the menus are required, the software application's code must be edited and recompiled. In large production systems, editing and recompiling software applications can be time-consuming and expensive. In result, such changes to CB menus can be delayed or left unimplemented.
No other limitation of the prior art is that existing CB menus are specifically designed to work with a specific application. In other words, a CB menu created for application X, would not work within application Y, because it is dependent on application X through its hard coded static menus.